Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/ospf/ospf-minutes-91jul.txt

Text File | 1993-02-17 | 7.4 KB | 197 lines

CURRENT_MEETING_REPORT_


Reported by John Moy/Proteon

OSPF Minutes

The OSPF Working Group met on Monday, July 29th at the Atlanta IETF. The
following topics were discussed:

OSPF trap MIB

Rob Coltun led a discussion of his OSPF Trap MIB document.  Briefly,
this document began as a list of traps to help implementors debug their
code.  But Rob has now changed it to include only those traps that would
be of use to a network manager.  This has decreased the size of the Trap
MIB significantly.  Also, the Trap MIB was separated from the rest of
the OSPF MIB in order to smooth the OSPF MIB's standardization path
(traps are still somewhat controversial).


It was decided that the following changes should be made to the Trap MIB
document.  After it is updated, the document will then be submitted to
the Network Management Directorate.


   o The ospfIfStateChange and ospfVirtIfStateChange traps will only
     occur when either a) the new interface state is one of the terminal
     states (``DR'', ``Backup'' or ``Other'') or b) the interface state
     regresses (e.g., goes from ``DR'' to ``Down'').

   o The ospfNbrStateChange and ospfVirtNbrStateChange traps will only
     occur when either a) the new neighbor state is one of the terminal
     states (``2-Way'' or ``Full'') or b) the neighbor state regresses
     (e.g., goes from ``2-Way'' to ``1-Way'').

   o A new authentication failure trap will be created, splitting off
     from the existing ospfConfigError trap.  This is because for net-
     works that are on the boundary of two ASes, authentication failures
     may be configured intentionally in order to separate two OSPF
     domains.

   o The reasons for the ospfRxBadPacket trap will be enumerated, just
     as the is currently done for the ospfConfigError trap.

   o The ospfOriginateLSA trap will not be invoked for simple refreshes
     of LSAs (which happen every 30 minutes), but instead will only be
     invoked when an LSA is (re)originated due to topology change.

   o The ospfMaxAgeLSA trap will only be invoked for those LSAs that the
     router itself ages to MaxAge (either normally or prematurely).  It
     will not be invoked when the router receives a MaxAge advertisement
     from a neighbor.

                                   1





   o The ospfFreeLSA trap will be removed, since its functionality is
     (pretty much) identical to that of the ospfMaxAgeLSA trap.



Not so stubby areas

Next, Vince Fuller led a discussion of the proposed new ``not so stubby
area'' option for OSPF. Briefly, the intent of this option is to create
a new type of area (the ``not so stubby area'' or NSSA), which would not
receive type 5 external LSAs from the backbone (and so would have a
small database size), but would be allowed to itself originate a small
number of external advertisements for distribution to the backbone.
This would allow small RIP clouds to be hung off of the NSSAs.


Vince Fuller and Rob Coltun are writing a document defining NSSAs.  The
intent is to add them in a backward compatible way to OSPF Version 2.


As far as mechanisms for implementing NSSAs, there were two competing
proposals, each differing on how the NSSA would represent the externals
it exports to the backbone.


   o Option 1.
     The externals would be originated as regular type 5 LSAs.  Flooding
     of type 5s between an NSSA and the backbone is unidirectional.
     Type 5s can be flooded from NSSAs to the backbone, but not vice
     versa.

     Advantages:  1) No conversion of the LSA would be necessary at the
     area border routers connecting the NSSA to the backbone.

     Disadvantages:  1) There would no longer be a global type 5
     database.  In fact, the type 5 database in the area border routers
     connecting the NSSAs to the backbone would be split into several
     pieces:  one for each NSSA, and one for those type 5s originated by
     the backbone.  Maintaining this split may prove difficult.

   o Option 2.
     The externals would be originated as a new LSA type (call it type 6
     LSAs).  The flooding of type 6 LSAs would be restricted to a single
     NSSA. The area border routers connecting the NSSA to the backbone
     would, in essence, convert the type 6 to a type 5 for distribution
     to the backbone.

     Advantages:  1) the type 5 database remains intact.  In addition,
     the flooding of type 6s is similar to the flooding of all other
     LSAs that are specific to a single area (i.e., type 1-4s).

     Disadvantages:  1) The ``conversion'' of type 6s to type 5s in the

                                   2





     border routers may be fairly complicated (editor's note:  at lunch
     Rob Coltun pointed out that the conversion could be made trivial by
     requiring that all type 6s be originated with forwarding
     addresses).  2) When there are multiple area border routers
     connect- ing the NSSA to the backbone, multiple type 5 LSAs may be
     produced for a single type 6 LSA. It was thought that this could be
     overcome by an election algorithm, if desired.

     Vince and Rob are going to further weigh the two approaches and
     then document their conclusions.



Non-broadcast Networks

Several people have noticed that OSPF's non-broadcast support could be
made more robust in the face of misconfiguration, and that the amount of
configuration (especially address translations) could be reduced by
using some of the mechanisms in Paul Tsuchiya's SMDS routing and
addressing internet draft (like ARP servers).  We attempted to find
some- one to write a document discussing these issues, but have as yet
been unsuccessful.


Joint Session with BGP Working Group

We also met in a joint session with the BGP Working Group, where we
reviewed Kannan Varadhan's document on BGP and OSPF interaction.
Kannan's document give rules for exporting OSPF routes to BGP, importing
BGP routes into OSPF, and defines how to set the OSPF external route tag
in a vendor-independent manner.  It also mandates that the OSPF router
ID and the BGP router ID be set identically, and explains the
circumstances where OSPF and BGP forwarding addresses should be used.

Attendees

Nagaraj Arunkumar        [e-mail]
Jim Beers                [e-mail]
Tom Benkart              [e-mail]
Nelson Bolyard           [e-mail]
Scott Brim               [e-mail]
Henry Clark              [e-mail]
Rob Coltun               [e-mail]
Dave Cullerot            [e-mail]
Dino Farinacci           [e-mail]
Dennis Ferguson          [e-mail]
Arlan Finestead          [e-mail]
Vince Fuller             [e-mail]
Robert Griffioen
Jeffrey Honig            [e-mail]
Phani Jujjavarapu        [e-mail]
Mark Lewis               [e-mail]
Joshua Littlefield       [e-mail]

                                   3





Brian Lloyd              [e-mail]
April Merrill            [e-mail]
Greg Minshall            [e-mail]
John Moy                 [e-mail]
Andy Nicholson           [e-mail]
Karen O'Donoghue         [e-mail]
Norman Patty
Joe Peck                 [e-mail]
Jason Perreault          [e-mail]
Roxanne Streeter         [e-mail]
Mike Truskowski          [e-mail]
Brian Wheeler            [e-mail]



                                   4